After an instruction enters the processor, it is passed to an instruction decoder. The instruction decoder reads the opcode field from the instruction and determines how the processor will execute the associated operation. In particular, the decoder decodes the instruction into execution control information, such as discrete control signals, microcode fetched from a data store, a combination of the two, or control information appropriate to other well known methods. The execution control information represents an execution flow which controls, in part, the operation of one or more different execution units to perform the operation specified by the instruction.
By way of example, FIG. 1 is a block diagram illustrating a prior art implementation of a processor 120 supporting a class of comparison operations using a single compare instruction 110. The compare instruction is received by the processor 120 and is provided to an instruction decoder 130. The instruction decoder 130 selects a compare microcode 134, which will cause the full range of comparison relationships to be performed, from a microcode table 136 and sends it to an execution unit 160. The execution unit 160 performs the full range of comparisons and sets a number of bits in a result register 162 with each bit corresponding to a different comparison condition. These bit combinations are then interpreted by other instructions to check for the desired condition.
In another example, FIG. 2 is a block diagram illustrating a prior art implementation of a processor supporting a class of comparison operations using a separate instruction for each comparison relationship. By way of example, FIG. 2 shows a compare-equal instruction 210 entering an instruction decoder 230 of a processor 220. Inside the instruction decoder 230, the compare-equal opcode 212 is used to pull the compare-equal microcode 235 from the microcode table 236. The compare-equal microcode causes an execution unit 260 to perform the compare-equal operation and store in a result register 262 either of all-1s or all-0s depending on the equality of the operands identified in the first operand field 214 and the second operand field 216. Because the execution unit produces the "all or nothing" result, each type of comparison relationship has a separate opcode in the decoder as shown in the microcode table 236. As such, the processor of FIG. 2 supports a separate instruction for each of the following comparison operations: compare-greater-than (CMPGT), compare-less-than (CMPLT), compare-equal (CMPE), compare-not-equal (CMPNE), compare-greater-than-or-equal (CMPGTE), and compare-less-than-or-equal (CMPLTE).
While the processor in FIG. 1 uses only one opcode space for the full range of comparisons, it has a drawback. Consider the following C source code statement: EQU X=(X&lt;0)?0:X; //If(X&lt;0)then X=0 else X=X
TABLE 1 Comparison of Execution using FIGS. 1 and 2 .sup. LOAD R1, X ; Load R1 LOAD R1, X ; Load R1 .sup. CMP R1, 0 ; Set Flags CMPGT R1, 0 ; R1 = 0 or 2.sup.32 -1 .sup. BRG A ; If &gt; jump AND R1, X ; R1 = X & R1 .sup. LOAD R1, 0 ; &lt; so zero R1 STOR X, R1 A: STOR X, R1 ; store back to X
The left column of Table 1 shows how the processor of FIG. 1 could execute the source code statement. The compare instruction (CMP) produces a series of flags which indicate the various comparison relationships. Next, the processor must check the flags for the result of the current comparison relationship of interest (e.g., greater-than, equal-to, etc.) to determine what value should be stored back into the source register, usually by using a conditional branch instruction of some type (e.g. branch-greater-than=BRG). Such branch instructions are costly in terms of execution and can be particularly troublesome in a highly pipelined system. However, the processor from FIG. 2 (shown in the right column) uses a compare-greater-than instruction to produce a result which can be used as a mask to the next operation. The AND operation preserves the contents of X if X was greater than zero. Thus, the processor of FIG. 2 yields a more efficient execution flow at the cost of opcode space.
In modern processors, the decoder can become quite complex. Several factors influence the overall complexity of a decoder including: the available die space, the number of signal paths required, the lengths of the signal paths, the number of opcodes handled, and the complexity of the circuitry required by the individual opcodes. An increase in the number of opcodes may increase the size of the decoder and can make it more difficult (or even impossible) to route suitable signal paths to support the required throughput of a given performance specification. Therefore, it is desirable to minimize the number of opcodes required for an instruction set.